NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/197

Internet Message Format | 1996-08-06 | 5KB

Path: ix.netcom.com!netnews
From: [e-mail] (Mike Rubenstein)
Newsgroups: comp.lang.c++,comp.lang.c,comp.std.c
Subject: Re: Hungarian notation
Date: Sat, 27 Jan 1996 03:00:21 GMT
Organization: Netcom
Message-ID: <[e-mail]>
References: <[e-mail]> <4d2ok0$[e-mail]> <[e-mail]> <[e-mail]> <4e1nd8$[e-mail]> <[e-mail]> <dewar.822407919@schonberg> <[e-mail]> <4e6oj9$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: ix-dc17-13.ix.netcom.com
X-NETCOM-Date: Fri Jan 26  7:00:35 PM PST 1996
X-Newsreader: Forte Agent .99c/16.141

[e-mail] (Jon S Anthony) wrote:

NOTE:  I've removed all groups from this posting except comp.lang.c
and comp.lang.c++ and have added cmp.std.c

Since I've added a new group, let me summarize a bit.  The discussion
revolves around the result of converting a signed integral type to a
smaller type when the value in the original cannot be represented in
the new type.

I claim that ISO 6.2.1.2 requires that an implementation actually do
such a conversion.  The implementor may choose the mapping.  Beside
the usual throwing away of high order bits, possibilities include
always using the value 0, or the largest possible value for the new
type, or, even, a random value.

However, I claim that a conversion is required -- the implementation
must come up with a value that can be represented in the new type and
use that.  It may not do other things like, as one person claimed,
deleting the system disk even if such action is documented.

> In article <[e-mail]> [e-mail] (Mike Rubenstein) writes:
>
> > [e-mail] (Jon S Anthony) wrote:
> >
> > > In article <[e-mail]> [e-mail] (Mike Rubenstein) writes:
> > >
> > > > I think you're reading something into my post that isn't there.
> > > >
> > > > What am I reading into the standard that's not there?  Nothing in my
> > > > post suggests that defining the result as always 0 is illegal.  In
> > > > fact, it is clearly legal.
> > > >
> > > > But the standard does impose some restrictions on the definition.  The
> > > > definition must specify that the subject type is converted to the
> > > > object type.  It must not produce side-effects.
> > > >
> > > > Please reread my post; I was responding to the statement that the
> > > > definition could be to delete the system disk.  That is out of bounds
> > > > for the definition and I said so.  I did not say that defining the
> > > > result to be 0 is out of bounds.
> > >
> > > Face it.  You just plain got it wrong.  Deleting the system disk is
> > > perfectly within bounds.  Stupid, for sure, as no one in their right
> > > mind would use such a compiler, but perfectly legal.
> >
> > Please cite anything in the standard that supports your position.  I
> > can find nothing in the standard that gives an implementation that
> > license.
> >
> > Insults do not prove a point -- quotes from the standard do.  I've
> > shown the passages that support my position.
>
> I don't see any insult here at all.  Sorry if you took it that way.
>
> Here's the relevant passage yet again:
>
>      When a value with integral type is demoted to a signed integer
>      with smaller size or an unsigned integer is converted to its
>      corresponding signed integer, if the value cannot be
>      represented the result is implementation defined.
>
> Now, the problem is (as James Kanze has pointed out) that the term
> "result" which you believe to know the "correct" definition of, is not
> defined.  Because of this it _could_ be taken as meaning "result of
> the computation".  You take it as a given that it means "result of the
> expression", i.e., its value.  But that is not clear, and so an
> interpretation given the former reading would indeed allow for
> virtually any sort of behavior as long as that behavior was
> documented.  As James Kanze pointed out, a very _reasonable_
> interpretation given this reading of "result" would be to to signal
> (raise) an exception.

I've not seen Jame's post, but I look forward to seeing it.

But, I don't see how the standard permits throwing an exception.  ISO
6.2 says

    Several operators convert operand values from one type to
    another automatically.  This subclause specifies the result
    required from such an implicit conversion, as well as those
    that result from a cast operation (an explicit conversion).

It seems obvious to me that if one uses correctly a construction that
the standard says converts a value from one type to another, then the
implementation must convert the value from one type to another -- it
may not do other things.  By definition (ISO 3.10)
implementation-defined behavior only applies to a correct program
construct and correct data.

I'm glad you intended no insult.  I'm afraid I just don't react well
to ex cathedra statements that I am wrong, particularly when I have
taken  care to give clear citations that I believe support my
position.

Michael M Rubenstein